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Foreword to the BTE Journal Publication of the 
Guideline 


INTRODUCTION 

This guideline is published as a Supplement to British Telecommunications Engineering 
Journal (BTE Journal) in the hope that it may be of use to those producing the large 
number of system requirements specifications (SRSs) written within British Telecom. 
When the first-named author’s article on the difficulties of specification was published in 
the April 1987 issue of the BTE Journal , there resulted over a dozen enquiries, from 
various parts of BT, about the SRS guideline referenced in it. These enquiries seemed to 
suggest that writers of specifications (and, almost certainly, other documents) throughout 
the business are aware of the need to improve the quality of documentation and to find 
tools not only to aid quality improvement but also to ease the writer’s task generally. This 
guideline is such a tool. It not only provides a model for writing an SRS, it is also a basis 
for checking one. (The inspection method of checking documents is described in an article 
in the current issue of the BTE Journal.) 

HISTORY 

Whereas the guideline has been in use in the authors’ Section in British Telecom 
International for some time, in the form of successive issues, a review of its history is 
appropriate. A European computer standards committee, on which one of the authors sits, 
developed two position papers (among others) which are referenced below [1, 2]. While 
these were in final draft form, the authors (of the current guideline) refined reference 1 
and added to it a great deal of appropriate material from reference 2. The resulting 
document was issued as the Section’s SRS guideline. Comments from users resulted in 
modifications, but it was also recognised that there were fundamental problems. The 
guideline was too bulky, there was too much redundancy, unfamiliar terms were too 
frequently used, some basic aspects of the structure of the document were misleading to 
some staff, and some essential points were not covered. The authors have therefore 
rewritten the guideline to correct these deficiencies. Where appropriate, improvements 
have been fed back to the original standards committee. 
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Preface 


A system requirements specification (SRS) is the means of communication between those 
defining a problem and those who are going to attempt to provide a solution. This guideline 
is intended to assist customers to produce a good SRS and thus give suppliers (whether 
in-house or not) the best possible chance of providing a system fit for its purpose. 

To have the best chance of producing a good SRS, an author should not only embody 
in it the topics identified in this guideline, as appropriate, in the order shown, but 
also consider the following attributes of the SRS itself: non-ambiguity, completeness, 
correctness, consistency, verifiability, modifiability and traceability of all requirements in 
the SRS. 


• An SRS is unambiguous only if every requirement described in it is unambiguous. 
A requirement is unambiguous if it has only one possible semantic interpretation. 

• An SRS is complete if it states the full set of the customer’s requirements, and each 
requirement has been stated in full. 

• An SRS is correct if every requirement stated in it has been verified by the customer. 

• An SRS is consistent if there is no conflict between any given set of requirements 
described in it. 

• An SRS is verifiable if every requirement stated in it is verifiable. A requirement is 
verifiable only if there exists some process by which the developed system can be checked 
to ensure that the requirement has been fulfilled. 

• An SRS is modifiable if its structure and style are such that any necessary changes 
to the requirements can be made easily, completely and consistently. 

• The requirements in an SRS are traceable if the origin of each of its requirements 
is clear and if the SRS facilitates the referencing of each requirement. 


It would be remarkable if an SRS achieved all these attributes perfectly, since customers’ 
requirements are arrived at through evolution rather than spontaneity. However, the use 
of guidelines forces the customer to consider, in the first instance, many points which may 
otherwise have been deferred until later, and it thus channels and accelerates the process 
of SRS production. An SRS seldom achieves absolute stability and can be expected to 
change many times during the system life cycle. A ‘frozen’ SRS is usually one which has 
artificially been held static at a particular time for a defined purpose; for example, for 
tendering. Once a project has commenced, the frozen SRS may change, but changes 
should only be in accordance with an agreed change-control procedure. This allows the 
customer to introduce necessary changes and the supplier to receive credit for the time 
and resources necessary for their implementation in the target system. 

At this point, it is worth commenting on the term ‘system requirements specification 
(SRS)’. This term is widely used, but is synonymous with others such as ‘statement of 
requirements (SOR)’ and ‘specification of customers’ requirements’. To clarify the term, 
an SRS is shown in its context within the project life cycle in Figure 1 of this guideline. 


Figure 1 

The SRS in the context of the project 
life cycle 
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There are two further important points to be made. First, the SRS is the customer’s 
responsibility. It may be written with assistance from consultants, or even the supplier, 
but it remains the customer’s responsibility. Second, the SRS is a requirements specification 
and not a system specification: it should state what the computer system is expected to 
do rather than what it should be. The translation of the SRS into a solution, that is, a 
particular computer system to do the job, is the supplier’s responsibility. 

A glance at the contents sheet will show that an SRS should cover a number of aspects 
of a project. Clearly the actual system’s requirements are essential. However, many 
projects come to grief because environmental requirements, such as interfaces, have not 
been specified; because the supplier has neglected to produce adequate documentation; or 
because the supplier’s project or quality control has been deficient. A customer stands the 
best chance of a useful product when these matters are covered in the SRS, and these 
guidelines show how this may be done. The guideline is thus intended to cover all aspects 
of requirements and should be used with some discretion, as all paragraph headings may 
not be relevant in all cases. However, they provide the frame on which requirements may 
be hung. 

Although this guideline has been drawn up as the result of experience and improved in 
the light of use, there are, no doubt, further improvements which could be made. Comments 
are therefore welcome. However, users of the guideline are particularly asked not to make 
changes unilaterally. If the guideline is to remain standard, all users should hold the same 
version, which means that change control must remain centralised. However, it cannot be 
denied that, for some areas of work, this document could be tailored to produce a more 
appropriate guideline. 

This guideline deals in detail with the form and content of a system requirements 
specification (SRS) document. An SRS should normally contain the sections described in 
the guideline and summarised in the contents list of Section 0. The text of the guideline 
amplifies the contents list, explaining the sections and what they should contain. As part 
of the explanations, there are, in some cases, checklists. These are for example only, and 
should not be thought of as either exhaustive or mandatory in any given case. 


Contact Point: 

Mr. F. Redmill 
British Telecom International 
PL/ID/NISM 
Lintas House 
15-19 New Fetter Lane 
LONDON 
EC4P 4EU 
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SRS Document 


O TITLE AND CONTENTS 

An SRS should have a meaningful title, which identifies the project for which it is written. 

Each requirement within the document should have a unique identifier and its position 
within the overall structure should be traceable logically (for example, by paragraph 
number). All major sections and paragraph numbers should be included in the contents 
list, and the recommended contents list is given below. Although all the headings in this 
contents list may not be necessary in all cases, it is recommended that those deemed to 
be unnecessary should be listed along with notes to show why they have been excluded. 
Reviewers thus have the benefit of the full checklist when performing their function. 


Contents List 

0 TITLE AND CONTENTS 

1 INTRODUCTION 

2 ABOUT THIS DOCUMENT 

2.1 Purpose 

2.2 Scope 

2.3 Background of Readers 

2.4 Inadequacies of the Document 

2.5 Legal and Contractual Aspects 

2.6 Document Maintenance 

3 DEFINITIONS OF TERMS USED IN THIS DOCUMENT 

4 TARGET SYSTEM IN CONTEXT 

4.1 Objectives 

4.2 The Target System in its Environment 

4.3 Related Projects 

4.4 Legal Aspects and Licensing 

5 TARGET SYSTEM REQUIREMENTS 

5.1 Purpose of The System 

5.2 Functions of The System 

5.3 Modes of Operation 

5.4 Interfaces 

5.5 Availability 

5.6 Reliability 

5.7 Maintainability 

5.8 Adaptability 

5.9 Security 

5.10 Safety 

5.11 Test and Maintenance Support 

5.12 Ergonomic Requirements 

5.13 Documentary Details 

5.14 Customer Imposed Constraints 

5.15 Allowable Compromises 

6 TARGET SYSTEM ENVIRONMENT REQUIREMENTS 

6.1 Requirements on the Target System Environment 

6.1.1 Effects on the Customer 

6.1.2 Training 

6.1.3 Operating Environment 

6.2 Requirements on the Target System 

7 DEVELOPMENT PROJECT REQUIREMENTS 

7.1 Infrastructure 

7.2 Managerial Details 

7.3 Documentary Details 

7.4 Business Relations 

7.5 Project Management 

7.6 Project Management Tools 

7.7 Quality Assurance 

8 INSTALLATION 

8.1 Physical Considerations 

8.2 Operational Considerations 

8.3 Responsibilities of the Customer 

8.4 Responsibilities of the Supplier 

8.5 Joint Responsibilities of the Customer and Supplier 

8.6 Clerk of Works 

9 ACCEPTANCE TEST PLANS AND CRITERIA 

10 REFERENCES 

11 APPENDICES 
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1 INTRODUCTION 

The SRS is the means of communication between those defining a problem and those who 
are going to attempt to provide a solution. 

The purpose of this section is to assist the reader to understand the problem to be 
solved. The section should therefore present background information relevant to an 
understanding of the problem, including the objectives to be met by its solution. 


2 ABOUT THIS DOCUMENT 

This section should assist the reader to understand the total SRS document. It should 
outline its scope and nature and, in particular, should address the aspects described in the 
following subsections. 

2.1 Purpose 

This section should contain a concise explanation of why the document has been produced 
(for example, ‘The intention of this document is to provide a detailed specification of the 
requirements for ..’). 

2.2 Scope 

A short description should be given of the areas covered by the SRS document. 

2.3 Background of Readers 

This section should indicate the background and responsibilities expected of potential 
readers. The document may contain sections which require more detailed technical 
knowledge in order to be understood. This section should indicate the different levels of 
knowledge required. 

2.4 Inadequacies of the Document 

The reader should be aware of the special attributes of the document, so as to be more 
effective in spotting errors or deficiencies. Typical attributes include non-ambiguity, 
completeness, consistency, verifiability, traceability of items and modifiability. These 
attributes are defined in the preface to this document. Some indication of the degree to 
which any given issue of the document embodies these characteristics should be given in 
this section. For example, if it is known that some requirements have not yet been 
determined, an overview of the incompleteness of the document should be given in this 
section. 

2.5 Legal and Contractual Aspects 

This section should contain any legal or contractual constraints both on the use of the 
document and implied by the existence or contents of the document. These may include 
ownership, responsibility, circulation, external regulations, etc. This is in addition to 
any standard classification or restriction markings which may appear elsewhere in the 
document. 

2.6 Document Maintenance 

After the SRS document has been completed (and development of the target system 
started), the SRS will need maintaining for the rest of the target system life cycle. Rules 
for such maintenance should be given, including allocation of responsibility and how 
changes should be handled. It is advisable to have formal rules for change control, with 
a single reference point nominated to co-ordinate and implement all changes and issue 
updates. A numbering system for identifying issues and updates should also be defined. 
A* machine-based system of documentation and change control, and thus an automatic 
means of document production, should be used if possible and, in any case, all changes 
throughout the life of the SRS should be traceable. Records should be kept of all versions 
of the document and the reasons for all changes. Typical reasons for modifications are: 
error correction, changes in the system environment, changes in the facilities required, 
and changes in technology. 

In the interest of standardisation and efficient management of a project, the document 
control point should maintain a list of all persons to whom updates of the document are 
to be distributed. Their titles, references and addresses should be included. 


3 DEFINITIONS OF TERMS USED IN THIS DOCUMENT 

This section should define all abbreviations, conventions, technical terms, concepts, and 
any common terms used with a special meaning in the document. This will increase the 
probability of the reader correctly understanding the SRS document. 
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4 TARGET SYSTEM IN CONTEXT 

It is essential to a good specification that the system is seen in a wide context. The purpose 
of this section is to describe the target system context, which is not limited merely to the 
physical environment. This section is essential for all who need to assess (judge, verify, 
validate) the system requirements. However, the descriptions here should be kept at a 
fairly high level, referring to other sections for more detail. 

4.1 Objectives 

The reasons for providing the system should be stated, with any expected benefits to the 
surroundings of installing the system (for example, safety enhancement, economic gain, 
improved functionality or new functions, resource efficiencies, etc.). 

4.2 The Target System in its Environment 

This section should contain a description of how the system will be embedded in its 
environment, both physical and logical. This includes its location and the interfaces 
between the system and its environment and an overview of its main functions and modes 
of operation. While this section should introduce environmental aspects, the forum for a 
more detailed description of the system in its environment is provided in Section 6. 

4.3 Related Projects 

It is often of value for the system designer to utilise information and experience from 
similar projects. The specifier should, where possible, provide references to and short 
descriptions of other relevant projects, past or present. 

4.4 Legal Aspects and Licensing 

This section should include details of any constraints placed on the system by laws and 
regulations (for example, The Data Protection Act). A short description of any necessary 
licensing procedure should also be included. 

5 TARGET SYSTEM REQUIREMENTS 

Requirements may range over the complete target system life cycle. This section must 
provide a definitive statement of the requirements of the target system, as far as these are 
dictated by the customer’s need and the system’s immediate environment. It should be 
usable as a basis for acceptance tests and it should give all the requirements that the 
design must satisfy. Metrics must be used (that is, requirements must be quantified) to 
eliminate disagreement over requirements and to provide criteria for acceptance tests. A 
good SRS can lead directly to a partial verification plan for the system, precisely because 
requirements are expressed in a form which facilitates the construction of tests and the 
evaluation of their results. 

One should be careful not to over specify. This happens all too often, and usually leads 
to a far from optimal solution (system) if it constrains the designers unduly. It is the 
customer’s needs which ought to be captured in the SRS, and not design proposals, ad 
hoc solutions or unnecessary constraints. 

5.1 Purpose of the System 

This section introduces the system, giving an overview of its purpose, expected performance 
and main requirements. As far as it is practicable, this should include a description of 
what the system should not do. 

5.2 Functions of the System 

All functions to be performed by the system in each of its modes of operation should be 
defined. It is advisable to identify the interfaces related to each of the functions, with 
inputs and outputs explicitly indicated. It is of considerable assistance to the designer if 
information can be given at this stage about the reasons for carrying out the particular 
functions. This information is also vital if subsequent changes in the specification are 
considered. The functions should be described in behavioural rather than procedural 
terms. 

Performance requirements and attributes should be given for each function. These 
should be quantified wherever possible so that the designer will know what criteria the 
system has to satisfy. Having to specify metrics for the system also focuses the customer’s 
mind and assists in the understanding of what is being asked for. 

The functions of the system should also be stated in terms of the transformations 
between its inputs and outputs. The correspondence between these and any stated objectives 
and constraints should be indicated. The inputs and outputs should be identified explicitly 
and referenced. 

These functional requirements should be further refined. Input and output handling 
functions should be derived together with any necessary validation functions (such 
as format, field or logic checks). Any necessary database maintenance, updating and 
information-retrieval functions should be specified. 
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Related data elements should be grouped and the group activity relationships (relation¬ 
ships between each data group and the inputs and outputs of the system) should be 
determined. Any special requirements should be identified. 

Checklist: 

• Major functions in each mode of operation. 

• Basic system states. 

• Transitions between states (allowable and not allowable). 

• Data storage requirements. 

• Interfaces related to particular functions. 

• Reasons for functions. 

• Performance requirements for each function (limits of variables, precision of function, 
data values, volumes and lifetimes). 

Finally, all the application-specific calculations or application-dependent data manipu¬ 
lations that must be carried out should be fully specified, preferably with the help of 
diagrams depicting functional and input/output (I/O) relationships. 

Care should be taken only to specify requirements and not methods of satisfying them. 

These are matters for the designer, who may be restricted and/or confused by design 
statements in the SRS. 

5.3 Modes of Operation 

This section should define all expected, permitted, and not-permitted modes of operation 
of the system. Details should also be given of the conditions of entry to, and exit from, 
each mode. 

Checklist: 

• System generation. 

• Installation of new software. 

• Start-up. 

• Self test. 

• Normal operations. 

• Emergency operations. 

• Degraded operation and failure modes. 

• Automatic operation. 

• Semi-automatic operation. 

• Manual operation. 

• Online (transaction processing or time-sharing). 

• Batch overnight processes. 

• Periodic processing (for example, weekly, monthly). 

• Maintenance. 

• Housekeeping. 

• Shutdown. 

• Error isolation. 

• Error recovery. 

• Back-up facility. 

5.4 Interfaces 

This topic was introduced in Section 5.2, but here it must be dealt with in a much more 
rigorous manner. Any man-machine interfaces should be described here, as should 
protocols. The information exchanges between the target system and adjacent systems 
should be identified and described. 

Checklists: 

ALL INTERFACES 

• Functions provided and required by the system and its processes. 

• Sequence of interactions. 

• Input/output files for batch transfer to/from other systems. 

• Nature of the information transferred. 

• Definition of printed/microfilm outputs. 

• Formats. 

• Available options. 

• Timing. 

• Frequency of demands. 

• Accuracy. 

• Message error rates and types. 

• Electrical characteristics (for example, voltages). 

• Mechanical/geometrical interface requirements. 

• Input checking. 

• Presentation formats. 
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• Information density. 

• Alerting signals. 

• Back-up, error correction. 

• Area where special human engineering effort is required (for example, critical control 
functions, sensitive areas, demanding tasks). 

• Security requirements. 

MAN-MACHINE INTERFACES 

• Positioning and layout of controls and displays. 

• Human reaction and decision times. 

• Security requirements. 

• Use of colours and blinking on displays. 

• Menu techniques. 

• Default values. 

• Response times. 

• Help facility. 

• Comfort signals. 

EQUIPMENT INTERFACES 

• Handshaking. 

• Error checks. 

• References to interface control documents, if these exist. 

• Input and output communication ports. 

• Communications protocols and procedures. 

• Interrupts. 

• Exception handling and error recovery. 

• Message formats. 

• Message throughput. 

5.5 Availability 

State the availability requirement for each mode of operation or function. These should 
always be quantified (for example, availability may be stated as the proportion of a day, 
week, etc., during which the system must be operational). Indicate the extent to which 
non-availability of particular functions is permissible. 

5.6 Reliability 

This section should define, numerically, the level of reliability required for the system, 
and for functions or components of the system and aspects of its operation. (Reliability 
may be defined as mean-time-between-failures (MTBF), and should be clearly dis¬ 
tinguished from availability.) All aspects of failure and error handling should be covered. 

Checklists: 

HARDWARE/SOFTWARE FAILURES 

• Failure detection. 

• Failure identification. 

• Failure isolation. 

• Redundancy. 

• Fail-safe operation. 

• Fault tolerance. 

SYSTEM RECOVERY PROCEDURES 

• Fallback procedures. 

• Reconstruction of obliterated or incorrectly altered data. 

INFORMATION COLLECTION 

• Separate sources. 

• Separate channels. 

INFORMATION PROCESSING 

• Data storage. 

• Error handling. 

HUMAN ERRORS OR VIOLATIONS 

• Security standards. 

• Control aspects. 

• Procedural aspects. 

• Management aspects. 
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5.7 Maintainability 

This section should cover the requirements for maintainability, giving acceptable figures 
for the major parameters (such as mean-time-to-repair). It may sometimes be appropriate 
to specify the methods or provisions by which the appropriate level of maintainability is 
to be achieved. 

Checklists: 

MAINTAINABILITY REQUIREMENTS 

• Maximum maintenance time. 

• Mean and maximum times to locate an error, to repair, to revalidate and to restart. 

MAINTAINABILITY AIDS 

• Accessibility. 

• Modularity. 

• Structure discipline. 

• Standardisation. 

• Interchangeability. 

• Fault traceability to replaceable units. 

• Test points. 

• Fault indicators. 

• Logging and evaluation of operating and fault history. 

• Preventive maintenance strategies. 

• Repair versus replacement. 

• Maintenance and repair cycles. 

• Spares provisioning (parts and suppliers). 

• Provision of fault isolation aids. 

• Maintenance documentation. 

5.8 Adaptability 

The requirements for the ability to tune the system to variations in demand or to 
incorporate foreseeable functional, data volume, and performance extensions should be 
defined. Anticipated operating situations and environments should be discussed and the 
limits to which adaptation should be catered for should be described. Any requirements 
for the portability of software between different hardware types should be specified. 

Checklist: 

• Rack space. 

• Interfaces. 

• Ports. 

• Volumes of equipment. 

• Processing power. 

• Computer storage. 

• Functions. 

• Demand. 

• Precision. 

• Variation of service available from the environment. 

• Safety. 

• Security. 

• Reliability. 

5.9 Security 

Security requirements should be defined in this section. Functions and data to be protected 
against general access or accidental/voluntary misuse or destruction should be nominated. 
Requirements should be specified for the type of protection, and acceptable probabilities 
for breaches of security should be given where possible. Data retention, replication and 
recovery requirements should also be specified. The methods or provisions by which system 
security is to be achieved should be defined. 

Checklist: 

• Loss or corruption under fault or recovery conditions. 

• Processing. 

• Data. 

• Communications. 

• Access. 

5.10 Safety 

In many applications, safety is not a criterion and this section would not need to be used. 
However, when it is of importance, there are two main areas of interest. First, the 
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requirements for safe operation of the system should be enumerated. These should include 
information about safe and unsafe states of the system and, if possible, the acceptable 
probabilities for entering an unsafe state. Second, requirements should be laid down for 
factors which could improve the level of safety. 

5.11 Test and Maintenance Support 

This section should define the test support products to be provided with the system. This 
may require provision of a set of test cases to exercise the system fully. It may require 
unit testers, test beds, or test drivers to be provided to execute the tests, or subsets of the 
tests, automatically, so as to allow efficient retesting. It may also require that tracing 
facilities be provided to allow visibility of the execution process, and execution thorough¬ 
ness, during testing. 

Checklist: 

• Test harness. 

• Test data generators. 

• Test cases (test data and results). 

• Unit testers. 

• Tracing facilities, for example, software diagnostics. 

5.12 Ergonomic Requirements 

This section should identify any areas of the system where special ergonomic considerations 
are required to optimise personnel effectiveness and/or promote safety and reliability. It 
should be ensured that the automated portions of the system are designed to aid and 
support the human portions, and not the reverse. In particular, any areas which could 
induce incorrect or unsafe actions because of operator misinterpretation (such as the 
display of incorrect, corrupted or outdated data in large quantity or confusing format) 
should be identified. 

The following are examples of what is relevant: 

• Man-machine interfaces and any related potential problems. 

• Operational procedures together with any potentially unsafe actions and their possible 
causes. 

• Human procedures within the system which are likely to be bottlenecks, or are likely 
to cause special problems to the system, such as operations which could give rise to errors. 

For each of these areas, and any others identified, the supplier should be required to 
state all operational, ergonomic and other engineering factors having a significant effect 
on human performance (for example, alternative hardware designs of video display unit 
stations which would influence the manual operation of the display). The human procedures 
that will require significant training or elaborate aids should be identified. 

5.13 Documentary Details 

This section should state all relevant documentation that is to be produced for the 
system components. It should define at what point in the system life cycle that specific 
documentation is required. Notice that the documentation should cover the whole of the 
system life cycle and include the operational and maintenance requirements. The supplier 
should be asked to define any guidelines and standards to be used for the production of 
documentation. 

Checklist: 

• Studies. 

• Analyses. 

• Design documents. 

• Lower level specifications. 

• Database documents. 

• Diagrams. 

• User and maintenance manuals. 

• Test and integration plan. 

• Test procedures. 

• Test reports. 

• Acceptance demonstration plan. 

• Certificates. 

• Installation drawings. 

• System layout. 

• Documentation of problems. 

• Historical information. 

• Documentation of any exceptions to the specification. 

• Training plans and materials. 

• Number of copies of documents. 

• Points in the development life cycle when each document should be delivered. 
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5.14 Customer Imposed Constraints 

The customer may wish to impose conditions which are not merely to fulfil the functional 
requirements. Reasons for this are, for example, political policy, or environmental con¬ 
straints. Constraints on requirements for the use or non-use of specific technical solutions 
should be listed. Such constraints may be necessary for achieving strategic goals (for 
example, the use of particular equipment), quality (for example, the use of certain parts 
or materials), or interfacing (for example, the use of defined communications protocols). 
However, it is recommended that customer imposed constraints should be minimised, and, 
indeed, none included unless absolutely necessary. 

5.15 Allowable Compromises 

Recognising that a supplier’s options are increased if compromises can be made between 
requirements, a customer may wish to indicate which requirements are mandatory and 
which may be traded-off against others. Priorities may also be given. To safeguard the 
customer, the supplier should be asked to indicate if and how this information has been 
used in a tender or design. A further safeguard is the statement of compliance given by 
a tenderer against each separate requirement. 

Examples of requirements which may be traded-off: 

• Functionality. 

• Development time. 

• Cost. 

• Reliability. 

• Availability. 


6 TARGET SYSTEM ENVIRONMENT REQUIREMENTS 

This section should contain those requirements on the target system environment which 
are necessitated by the introduction of the target system, and those requirements on the 
target system which may be enforced by the operating environment. 

6.1 Requirements on the Target System Environment 

6.1.1 Effects on the Customer 

The success of the system in its overall life cycle places requirements on the customer. 

The customer should require the supplier to identify the necessary qualities and competence 
of staff for the discharge of the customer’s responsibilities throughout the system life 
cycle. These can include the development of specifications and procedures, the installation 
and acceptance testing of the system, its operation, its maintenance and its eventual 
decommissioning. 

6.1.2 Training 

This section should require the supplier to identify the training requirements of all staff 
for their roles in the target system environment, throughout the system life cycle. The full 
training program, including retraining, throughout the whole of the system life cycle, 
including who is responsible for satisfying each training requirement identified, should be 
asked for. 

6.1.3 Operating Environment 

The supplier should be required to define any special aspects of the environment necessary 
for the correct operation of the target system. 

6.2 Requirements on the Target System 

If any aspects of the operating environment could potentially affect the design of the 
target system, they should be stated here. For example, if the system is expected to operate 
in an uncontrolled environment, the ranges of temperature and humidity should be defined. 

Checklist: 

• Power (phases, voltage, surges, limits, internal impedance, etc.). 

• Temperature. 

• Heat dissipation. 

• Humidity. 

• Electromagnetic compatibility. 

• Electrostatic discharge protection. 

• Dust. 

• Fire. 

• Sabotage. 
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7 DEVELOPMENT PROJECT REQUIREMENTS 

For projects being put out to contract, it is necessary not only to specify the requirements 
to be met by the target system, but also to request the supplier (or tenderers in general) 
to provide certain information which would increase confidence in their ability to carry 
out the project successfully and to comply with certain project requirements which would 
increase the chance of achieving a quality product. 

7.1 Infrastructure 

Certain aspects of the organisation of the supplier may directly affect the particular 
development project. If the customer is a public corporation, such aspects may also have 
a bearing on the acceptability, for reasons other than technical, of a contract with 
the supplier. The customer may demand certain information concerning the structure, 
operations and objectives of the supplier company. These may include legal status or 
professional accreditation, associated professional or commercial activities and employer- 
employee relations. Conditions of employment and policies on training, promotion and 
security may also be relevant. Future trends also have to be considered as far as it is 
practicable and important. 

7.2 Managerial Details 

This section should require the supplier to define any special requirements on the personnel 
and procedures involved in the development process, and to detail these separately for the 
different phases of the project. 

Checklist: 

• Education. 

• Training. 

• Skill. 

• Security. 

• Availability. 

• Responsibility. 

7.3 Documentary Details 

This section should require the supplier to detail the project management records and 
documents relevant to the project. 

7.4 Business Relations 

The organisation of relations between customer and supplier should be detailed. This may 
include statements about the way in which information may formally be exchanged 
between customer and supplier. Details in this section may also include the production 
schedule to be met by the supplier, control procedures for changes to the SRS, any follow¬ 
up planning, and the necessary documentation to be exchanged at key milestones. 

7.5 Project Management 

Problems could occur if no one has, or will assume and exercise, the authority to direct 
and co-ordinate the total effort within the project. A requirement for an overall project 
manager, to have jurisdiction over the whole project team, within the constraints of the 
project, should be stated and his curriculum vitae may be asked for. The customer should 
also indicate the degree of involvement which he requires in the development project, 
giving details of nominated project officers, with responsibilities for monitoring specific 
aspects of the development project. Where there is more than one supplier, each should 
be required to define his plan for carrying out his part of the project. 

7.6 Project Management Tools 

If appropriate, the supplier should be required to state what project management tools 
(for example, proprietary systems, software packages, etc.) will be used on the project. 

The customer may also choose to state an intention to use defined project management 
tools. 

7.7 Quality Assurance 

The supplier should be required to provide the customer with details of quality assurance 
to be invoked during the project. These should include the inspection, audit, test and 
analysis procedures to be applied, the interpretation of the results, the acceptance criteria 
to be adopted and the confidence limits to be achieved. They should also include a project 
plan, a quality plan, the standards to be employed at each stage of the project, the manner 
of their application, and the means of ensuring and auditing their application. The 
supplier’s configuration management plan should also be asked for. Requirements for the 
customer to police the project and carry out audits of the supplier’s adherence to their 
quality system should also be stated. 
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8 INSTALLATION 

This section should list the responsibilities of the customer and the supplier(s) regarding 
physical installation of the proposed system. 

8.1 Physical Considerations 

Details of how and where the new system should be physically installed should be given. 

Checklist: 

• Site location. 

• Site Access (lift sizes etc.). 

• Floor loading. 

• Floor, ceiling and lighting (type and dimensions). 

• Office and storage accommodation. 

• Installation staff facilities. 

• Packing Material (storage and removal). 


8.2 Operational Considerations 

The requirements placed on the installation work in order to present the minimum 
disturbance to the environment during installation should be stated. 

Checklist: 

• Other computer systems. 

• Workstations and operator terminals. 

• Operational interruptions when connecting the new system. 

• Power interruptions. 

• Data integrity and conversion. 


8.3 Responsibilities of the Customer 

This section should detail those aspects of installation for which the customer is prepared 
to assume responsibility. 

Checklist: 

• Provision of communication and data links. 

• Peripherals, for example, terminals and printers. 

• Power-supply cables. 

• Details of existing under-floor electrical trunking. 

• Test equipment cables and/or sockets. 

• False floor cut-outs. 

• Building work. 

• Fire instructions and any other relevant site instructions. 

• Passcards for suppliers’ access to site. 


8.4 Responsibilities of the Supplier 

This section should detail those aspects for which the supplier is required to take 
responsibility. 

Checklist: 

• Installation drawings. 

• Installation as per agreed layout. 

• Inter-equipment cabling and safety earths. 

• Making good any holes or damage and fire-stopping. 

• Ensuring that staff observe electrostatic discharge protection precautions, where 
appropriate. 

• Compliance with relevant statutory instructions, regulations and standards; for 
example, those of the British Standards Institution, Health and Safety at Work Act, 
Institution of Electrical Engineers. 


8.5 Joint Responsibilities of the Customer and Supplier 

This section should define joint activities. 

Checklist: 

• Siting of equipment. 

• Agreement of cable routes. 

• Preparation of installation schedule. 
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8.6 Clerk of Works 

It is normal practice for the customer to appoint a Clerk of Works who is resident at the 
installation site and would deal directly with the supplier regarding installation queries 
and problems. When appropriate, a statement similar to the following should be used: 
‘The Clerk of Works will be the customer’s representative on site for the duration of the 
installation and acceptance testing period. Any queries on site relating to installation shall 
be addressed to the Clerk of Works’. 

9 ACCEPTANCE TEST PLANS AND CRITERIA 

It is the customer’s responsibility to determine the criteria for the acceptance of the target 
system and for drawing up the plans for testing it. The tests and criteria need to be 
produced at the specification stage rather than, as too often happens, ‘any time before the 
end of the development stage’. Advantages of this are that they can be used as a means 
of verifying the SRS and, in giving the supplier notice of the nature of the tests, assist 
him in the design of the system. It has already been stated that requirements in the SRS 
should not be defined loosely, but should be given numeric values. The acceptance test 
criteria should, therefore, normally reflect these metrics. 

Acceptance tests are tests of functionality and are intended to discover whether the 
system meets the SRS. They should define how the customer needs to be satisfied that 
the criteria are met by the target system. Typically, they should list the tests that the 
customer intends to perform on the system, the conditions under which the tests will be 
run, the duration of the tests, the means and scales of measuring the results of the tests, 
the criteria of satisfactory completion of each test, and the criteria for acceptance of the 
system. 

Since acceptance testing is normally carried out under operational conditions, the 
customer may wish to lay down conditions which must be met before acceptance testing 
is allowed to commence. [The intention here is to gain confidence that the system will not 
jeopardise the customer’s operations in any way, and this is particularly important in real¬ 
time applications.] For example, the customer may wish to inspect the supplier’s validation 
testing and its results and/or the tests, test cases and their documented results throughout 
the development life cycle. 

It is recommended that acceptance test criteria and plans be included in this section of 
the SRS. They may, otherwise, comprise a separate document, but, in any case, they 
should constitute an end product of the specification stage of the project. 

10 REFERENCES 

This section should contain a list of all references to sources outside the SRS document, 
including standards, recommendations, guidelines and other documents relevant to or 
supporting the development of the SRS. It may also contain cross-reference lists showing 
where these external references, or defined words, phrases, or acronyms, are used within 
the SRS itself. Notice, however, that it is not feasible to place references in the referenced 
material, pointing back to the SRS. Changes in such material are therefore, as a rule, not 
communicated to the writer of the SRS, and this can cause a document maintenance 
problem. The SRS document should be as self-contained as possible, with relevant sections 
of supporting material being included whenever feasible, rather than being referenced. 
When referencing is unavoidable, care should be taken to identify the precise issue or 
version and date of the documents being referenced. 

11 APPENDICES 

It may, in some cases, be useful to place supporting material in appendices, rather than 
in the main body of the SRS document. However, such appendices should be physical 
parts of the SRS document and not separated from it. All the paragraph titles listed in 
this standard should be included in the main body of the SRS, with references to 
appendices containing supporting information when appropriate. 
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